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SECTION  1 .  INTRODUCTION 


To  manage  is  to  plan  for,  to  allocate,  and  to  conserve  resources. 
Data  is  a  resource.  It  has  the  same  characteristics  of  cost,  value,  and 
scarcity,  as  do  the  more  familiar  material,  financial,  and  personnel 
resources.  As  the  recognition  of  the  value  and  cost  of  information 
increases  in  the  Department  of  Defense,  the  effective  management  of  this 
resource  becomes  increasingly  important  to  Headquarters,  Defense 
Logistics  Agency  (HQ,  DLA) . 

Considering  the  size  and  complexity  of  operations,  the  management 
structure,  and  the  impact  of  its  decisions,  DLA  needs  to  have  the  best 
information  available  for  decision-making.  Effective  management  of 
information  entails  understanding  what  data  is  available,  keeping  track 
of  where  the  data  is,  and  knowing  who  is  responsible  for  it.  In  a  large 
organization,  such  as  DLA,  this  is  extremely  difficult.  Each  individual 
agency  is  capable  of  managing  its  own  data,  but  there  is  no  explicit 
management  of  the  data  that  flows  among  organizational  groups  or  across 
systems.  Furthermore,  the  individual  groups  and  systems  tends  to  manage 
their  own  data  in  different  ways,  making  the  correlation  of  data  at 
higher  levels  difficult  or  impossible.  Who  has  access  to  the  data,  who 
actually  uses  the  data,  under  what  conditions  are  the  data  valid,  when 
can  it  be  released  by  an  organization,  when  can  it  be  removed  or  changed, 
how  can  it  be  shared  among  organizations,  are  all  questions  relevant  to 
the  management  of  the  data  resource. 
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Such  questions  are,  at  best,  difficult  and,  sometimes,  impossible  to 
answer  consistently  across  DLA.  And  yet,  the  answers  to  such  questions 
are  central  to  data  sharing  to  achieve  improved  management  reporting  and 
more  effective  decision-making. 

The  problems  associated  with  managing  the  data  resource  can  be 
grouped  loosely  into  two  categories:  management  and  technical.  In  the 
management  category  are  the  issues  of  setting  information  management 
goals  and  directions,  of  establishing  information  management  policies  and 
plans  for  achieving  those  goals,  and  finally  of  managing  the  execution  of 
the  information  management  plan.  The  technical  problems  deal  with  the 
details  of  implementation. 

The  purpose  of  this  introductory  chapter  is  to  acquaint  the  reader 
with  the  Data/Data  Base  Administration: 

•  Study  Objectives 

•  Study  Methodology 

•  Scope  of  Study 

A  discussion  of  each  of  these  categories  follows. 

1.1  Study  Objectives 

DLA  is  committed  to  installing  commercial  DBMSs  throughout  the 
Agency.  In  order  to  utilize  data  base  technology  in  the  most  effective 
manner,  the  goal  of  this  study  is  to  conduct  an  extensive  review  and 
assessment  of  existing  Data/Data  Base  Administration  methods  and 


and  an 


procedures  and  to  develop  concepts,  directions, 

organizational  approach  for  use  by  DLA  in  accomplishing  the 
management  of  automated  information  DLA  wide.  The  specific 
objectives  of  this  study  are:  (see  Exhibit  1-1) 

•  Assess  the  current  Data/Data  Base  Administration 
Environment  on  a  DEA  Wide  Scope  and  document  the  results 
of  that  review; 

•  Make  recommendations  for  organizing  and  conducting  the 
Data/Data  Base  Administration  functions;  and 

•  Development  of  a  Time-Phased  Plan  for  Implementing  the 
Data/Data  Base  Administration  Program 

In  the  first  phase  of  this  study,  we  concentrated  on  assessing  the 
existing  data/data  base  administration  environment  within  DLA  today.  We 
presented  the  results  of  that  assessment  in  a  separate  report  and 
briefing  to  DLA  in  August  1984.  Section  2  of  this  report  provides  a 
summary  of  those  key  issues  that  surfaced  in  our  assessment  of  the 
current  DLA  D/DBA  environment. 

1.2  Study  Methodology  Employed 

An  overview  of  the  methodology  employed  by  Advanced  Technology  is 
presented  in  Exhibit  1-2.  As  indicated  in  the  exhibit,  the  development 
of  an  effective  Data/Data  Base  Administration  program  was  based  initially 
upon  developing  a  sound  understanding  of  the  current  D/DBA  environment 
DLA  wide. 


J 

1 


■-  .  -I 


1 


1-3 


foject  Objectives 


M 

c 

<0  Q) 

Id  E 
Q  JJ 

cS  To 

“  § 

>■« 
^  N 

o  •? 
^  § 
m  ? 
,.  O 

£< 

v>  ^ 
go 

O  0) 

£€ 
®  » 

•=l 

S’  I 
“  < 
5  c 

o 

^  *5 

o  2 

S  ^ 

•11 

c  £ 
.=  *0 

E< 

V  o> 

t;  ® 
®  Q 

O  00 


E 

(0 

O) 

o 


(A 


0. 

c< 

.2  ^ 

2  0) 

£ 

<A  4iirf 

1  > 

E  § 

■o  .s 

<  Z 

<0  ® 

(A  7 
(0  LU  ® 
00  ® 

«  O 
®  O)  ^ 

IS  ®  2 
Q  |2  I 

*5  "S  ^ 

=  D  i 

0^0 

*5  «  *s 

®  QQ  C 
“O  " 

c  c  -a 
0)  (0  0) 
EO  ^ 

o  ®  o 
o  2  ts 

oc  S  < 


® 

3 

u 

3 

^  ® 
o  « 

S«B 

Id  .2 

«-|  E 

•=  ^ 

E<  ? 

5  |2  0. 

®  -3  C 

<A  3  0 

«-3  I 

S  ®  I 

®  fic  S 

5  CA  ® 

®  ®  s 

15.2  c 

“5.2 
^  ^ 
o  >  g 

c  cQ  i 
O  (A  o 
*3  ® 

(0  ®  c 

■DO” 

c  ®  -o 

®  z  ® 

111 
0^0 
®  -o  ts 
®  c  5 
cc  ®  < 


EXHIBIT  1,1  D/DBA  PROJECT  OBJECTIVES 


Dovelopment  of  a  Time-Phasad  Plan  for  Implamanting  the 
Data/Data  Base  Administration  Program. 


SECTION  3.  PRINCIPLES  OF  D/DBA  ENVIRONMENT 


Data  Base  is  a  change  in  management,  not  merely  a  change  in 
software.  The  maximum  benefits  of  a  data  base  environment  are  realized 
by  an  organization  when  it  recognizes  data  as  a  resource;  similar  to  the 
value  of  managing  money.  Considering  the  amount  of  time  and  resources 
that  are  invested  in  the  collection,  storage,  and  reporting  of  data,  it 
is  a  logical  step  to  manage  data  like  other  organizational  resources. 

This  section  presents  some  basic  principles  that  need  to  be  accepted 
if  an  organisation  is  to  achieve  a  well-managed  data  base  environment. 

3.1  Management  Perspective 

Data  are  sufficiently  important  to  merit  specialized  and  high  level 
management  attention.  A  shift  in  the  management  perspective  of  this  size 
requires  the  acceptance  of  the  following  three  principles  by  top 
management : 


•  A  DATA  BASE  ENVIRONMENT  IS  A  CHANGE  IN  MANAGEMENT,  NOT  MERELY  A 
CHANGE  IN  SOFTWARE 

Data  in  an  organization  should  be  managed  directly  and 
separately  from  the  functions  which  use  that  data. 

Data  Base  Management  Systems  are  a  tool  to  store  and  retrieve 
data.  The  effective  management  of  the  data  is  the  foundation 
for  the  effective  use  of  a  DBMS.  Data  should  be  treated  as  a 
primary  resource  in  their  own  right,  independently  of  current 
machines  and  systems. 
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DLA  D/DBA  SIGNIFICANT  ISSUES 


RECOGNIZED  ISSUE 


REQUIREMENT 


•  Lack  of  DLA-wide  strategic 
planning  of  data 

•  Lack  of  detailed  knowledge  on 
degree  of  data  sharing  across 
systems  and  functions 

•  Current  D/DBA  policies/procedures 
embedded  in  LCM  procedures  inhibits 
effective  management  of  data  as  a 
resource 


DLA-wide  strategic  data 
planning 

Integrated  data  planning, 
integrated  automated 
tools 

More  explication  of  D/DBA 
objectives,  policies, 
procedures 


•  Lack  of  an  extensive  and  institu¬ 
tionalized  D/DBA  training/education 
program 

•  Enforcement  of  data  element  standards 


•  Current  data  dictionaries  do  not 
fully  support  data  element 
standardization 


Appropriate  education  for 
all  involved  end-users 


More  centralized 
authority  and  control 

Implementation  of  active 
and  passive  data 
dictionaries  that  inter¬ 
face  with  one  another 


Flexibility 


Develop  procedures  to 
permit  data-base  change 
with  minimum  impact  on 
application  systems 


EXHIBIT  2-4 


Subsequent  sections  provide  some  basic  principles  for  effectively 
managing  an  organization's  Data/Data  Base  environment.  These  principles 
and  the  key  findings  in  this  section  are  then  used  to  develop  a  general 
design  framework  for  DLA's  D/DBA  administration  functions. 


•  LACK  OF  FLEXIBILITY  -  The  DLA  major  AISs  are  designed  and 
implemented  for  a  static  environment.  Organizations  change 
over  time  and  the  application  system  must  adapt  with  them. 
Systems  that  are  inflexible  are  slow  to  change  and  very 
costly  to  maintain. 


The  issues  identified  in  Exhibit  2-4  have  been  developed  from 
specific  issues  at  individual  DLA  sites.  As  an  example,  our  discussions 
of  several  sites  resulted  in  the  following  observations. 


•  Some  changes  at  DLSC  take  two  years  for  approval,  indicating 
inflexibility 

•  DLSC  had  to  create  its  own  training  program 

•  The  DLSC  data  dictionary  is  independent  of  the  DBMS, 
therefore  it  does  not  enforce  standards 

•  DSAC-M  did  not  believe  that  D/DBA  responsibilities  were 
clearly  defined;  supporting  the  issue  of  D/DBA  policies  and 
procedures  were  embedded  in  LCM  procedures. 

•  Different  organizations  used  different  DD/Ds  and  no  specific 
organization  claimed  responsibility  for  strategic  data 
planning. 


Although  these  issues  have  been  found  in  DLA,  they  are  not  unique; 
they  can  be  found  in  other  organizations.  Many  of  these  issues  can  be 
addressed  providing  a  change  in  management  emphasis  takes  place. 


Exhibit  2-4  identifies  the  requirements  for  DLA  to  resolve  these 
issues.  The  underlining  theme  to  these  requirements  is  that  DLA  should 
view  data  as  a  resource  and  to  manage  it,  like  other  resources  (e.g., 
money).  This  will  require  DLA  to  change  its  mind  set  as  to  the 
importance  of  data  as  a  resource. 
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Exhibit  2-4  lists  the  major  D/DBA  findings  that  were  identified 
during  the  study.  A  discussion  of  each  finding  follows: 


•  LACK  OF  STRATEGIC  DATA  PLANNING  -  Currently  there  is  no  DLA 

wide  strategic  data  planning.  Future  effective  management  of 
an  organization's  data  base  environment  requires  high  level 
views  and  functional  views  of  the  data.  This  top  level  data 
planning  function  identifies  future  information  requirements, 
who  are  the  'owners'  of  the  data,  and  who  are  the  'users'  of 
the  data.  Lack  of  this  data  planning  prevents  the  maximum 
value  of  the  data  that  is  collected  and  used  from  being 
utilized.  Anticipating  future  data  needs  is  one 

consideration  of  the  strategic  plan. 

•  LACK  OF  DETAIL  DATA  SHARING  KNOWLEDGE  -  DLA  is  not  currently 
aware  of  the  data  sharing  among  its  major  systems  or  the 
potential  impact  of  converting  independent  batch  systems  into 
data  sharing  interactive  systems.  This  information  gap 
prevents  the  data  from  being  organized  in  its  most  stable 
form.  Unstable  data  will  increase  software  maintenance  costs 
over  the  long  term. 

•  CURRENT  D/DBA  POLICIES/PROCEDURES  EMBEDDED  IN  LCM  PROCEDURES 
-  Data  as  a  resource  is  a  concept  not  presently  held  by  DLA 
management.  Embedded  D/DBA  policies  and  procedures  hinders 
the  acceptance  of  da*:.,  being  managed  as  a  resource  and  its 
importance  being  diminished. 

•  LACK  OF  AN  EXTENSIVE  AND  INSTITUTIONALIZED  D/DBA 
TRAINING/EDUCATION  PROGRAM  -  Data/Data  Base  Administration 
concepts  have  evolved  greatly  over  the  last  few  years.  The 
lack  of  a  formal  DLA  D/DBA  training/education  program  causes 
implementation  problems  due  to  a  lack  of  understanding  data 
base  principles.  End  users  do  not  fully  understand  the 
importance  of  up-front  analysis. 

•  ENFORCEMENT  OF  DATA  ELEMENT  STANDARDS  -  DLA  does  not  maintain 
nor  uniformally  use  a  central  data  dictionary  which  hinders 
Data  Element  Standardization.  This  causes  incompatibility 
between  application  systems,  the  lack  of  data  sharing,  and 
excessive  effort  collecting  and  maintaining  data. 

•  CURRENT  DATA  DICTIONARIES  DO  NOT  FULLY  SUPPORT  DATA  ELEMENT 
STANDARDIZATION  -  because  they  are  not  used  in  the  analysis, 
design,  and  implementation  life  cycle  phases.  This  permits 
non-standard  data  being  defined  and  human  intervention  being 
required  to  manage  the  metadata  and  most  steps  of  the  AIS 
development . 
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Data/Data  Base  Administration 

Existing  Standards,  Policies, 
and  Procedures  (Continued) 


Specific  to  Data/Data  Base  Management. 


Individuals  consulted  during  our  visits  to  the  field  sites  generally 
included  the  ADP  Director,  Systems  Managers,  Data  Administrators,  Data 
Base  Administrators,  Operations  Managers  and  other  key  personnel  as 
selected  by  the  ADP  Director.  Current  approaches  as  well  as  future  plans 
for  operation  and  administration  of  the  D/DBA  environment  were 
discussed.  The  field  site  interviews  provided  personnel  at  these 
installations  an  opportunity  to  comment  on  and  participate  in  the  study 
effort.  Prior  to  any  field  visits,  the  project  staff  reviewed  any 
relevant  background  documentation  provided  by  DLA  HQ.  From  this  review, 
we  developed  specific  questions  to  supplement  our  standard  set  of 
questions. 

As  an  example  of  our  review  and  evaluation  of  the  current  D/DBA 
environment.  Exhibit  2-2  shows  a  sample  of  current  DLA  documents  that  we 
examined  and  the  extent  they  did  or  did  not  provide  specific  guidance, 
policies,  or  procedures  on  Data/Data  Base  Administration.  Exhibit  2-3 
provides  a  summary  of  DLA’s  current  experiences  with  DBMSs  and  data 
dictionaries . 


I 


2.2  Summary  of  D/DBA  Analysis  Results  and  Key  Issues 


The  results  of  our  analysis  of  the  current  DLA  D/DBA  environment  led 


to  a  number  of  key  findings.  We  present  a  summary  of  these  key  findings 
in  this  section.  The  reader  is  encouraged  to  read  the  separate  document 
for  more  detailed  backup  information. 


results  of  these  two  research  methods  provided  an  overview  of  relevant 
data/data  base  administration  activities  as  currently  performed  and 
administered  at  the  DLA  Headquarters,  Central  Design  Agencies,  and  the 
Primary  Level  Field  Activities. 

As  stated,  our  initial  focus  was  directed  toward  gaining  a  greater 
understanding  of  DLA  efforts  to  manage  information.  Documentation 
containing  DLA  ADP  policies  and  procedures  was  reviewed.  Exhibit  2-1 
lists  the  docviments  used  for  review.  The  documents  that  we  reviewed 
provided  an  overall  view  of  DLA's  ADP  environment  from  which  specific 
data/database  administration  functions,  responsibilities  and  procedures 
were  extracted.  We  analyzed  these  specific  policies  and  procedures  to 
determine  the  roles  of  different  DLA  organizations  currently  involved  in 
some  aspect  of  data/database  administration. 

The  other  source  of  data  administration  information  came  from  a 
series  of  structured  interviews  with  key  personnel  at  DLA  HQ,  selected 
CDAs  and  PLFAs.  At  least  one  site  from  each  of  the  Supply  Centers, 
Depots,  Service  Centers  and  DCASRs  was  chosen  for  interviews  as  well  as 
DLA-ZP,  DLA-ZS  and  DLA-ZW.  Exhibit  2-1  identified  those  sites 
interviewed.  Information  was  sought  specifically  in  the  areas  of 
data/database  administration  policies  and  programs  currently  being 
practiced  at  HQ  and  the  sites.  Interactions  that  PLFAs  have  between 
themselves  and  with  DLA  HQ  were  also  examined,  focusing  on  the  strengths 
and  weaknesses  of  current  D/DBA  standards,  policies,  and  procedures. 
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EXHIBIT  2.1  D/DBA  INFORMATICS  SOURCES 


SECTION  2.  CURRENT  DLA/DBA  ENVIRONMENT 


The  development  of  an  effective  data/database  administration  program 
for  DLA  requires  a  sound  understanding  of  the  current  data/database 
envi ronment . 

During  the  period  June  through  August  1984  we  accomplished  an 
extensive  survey  and  review  of  DLA's  current  D/DBA  environment.  The 
results  were  published  in  a  separate  report  and  briefed  to  DLA  in  August 
1984.  This  section  provides  a  summary  of  those  results.  The  reader  is 
referred  to  the  separate  document  for  more  detailed  backup  information. 

2.1  Current  D/DBA  Analysis  Approach 

Our  approach  to  surveying  the  current  DLA  D/DBA  environment  involved: 

•  An  extensive  review  of  existing  DLA  standards,  policies,  and 
procedures,  and 

•  Conducting  structured  interviews. 

We  first  gathered  documentation  on  standards,  policies  and  procedures 
pertaining  to  data/database  administration.  This  documentation  was 
supplemented  with  information  collected  from  structured  interviews 
conducted  at  both  HQ  DLA  and  various  field  sites.  Exhibit  2-1  shows  the 
documents  we  reviewed  and  the  sites  we  visited.  Knowledge  of  Automated 
Information  Systems  (AIS)  and  management  practices,  with  regard  to 
data/database  administration,  was  obtained  during  these  visits.  The 


Section  4,  General  Design  Framework,  identifies  the  required 
functions  and  tools  needed  to  manage  the  Data/data  base  environment. 
This  section  addresses  the  first  two  questions. 

Section  5  presents  alternative  considerations  for  locating  the 
required  D/DBA  functions  and  tools  within  a  proposed  DLA  D/DBA 
organizational  structure.  We  discuss  the  advantages/disadvantages  of  the 
identified  D/DBA  positions  within  the  DLA  organizational  structure.  A 
recommended  organizational  structure  concludes  this  section. 


Finally,  Implementation  considerations  are  discussed  in  Section  6. 


D/DBA  ANALYSIS  METHODOLOGY 
EXHIBIT  1-2 


1.3  Scope  of  Study 


In  order  to  understand  the  impact  and  direction  of  the 

recommendations  developed  in  this  report,  it  is  important  to  clearly 
recognize  the  limited  scope  of  this  study. 

The  scope  of  this  study,  and  consequently  the  Data/Data  Base 

Administration  program,  has  been  limited  to  the  automated  data  used  by 
DLA.  It  does  not  include  manual  information  collected  on  forms  or 
reported  on  hand  written  or  typed  sheets.  The  study’s  principle  focus 
was  on  managing  and  administering  the  DLA  Data/Data  Base  environment. 

The  reader  is  cautioned  to  keep  this  restriction  in  mind.  This  study 
is  not  an  Information  Resource  Management  (IRM)  study.  We  consider  this 
restriction  to  be  reasonable  given  the  contractual  constraints  on  time 
and  resources.  We  believe  this  is  an  appropriate  first  step.  Our 

findings  and  recommendation  in  this  report  address  the  following  three 
questions: 

•  What  D/DBA  functions  have  to  be  performed  to  effectively 

manage  the  D/DBA  environment  in  DLA? 

•  What  tools  are  needed  to  support  the  D/DBA  functions? 

•  What  is  the  required  organizational  structure  for  the 
functions  and  tools  and  where  should  they  be  located 
throughout  DLA? 

Prior  to  specifically  addressing  these  questions,  we  provide 
some  basic  principles  and  concepts  for  managing  a  Data/Data  Base 
Environment.  This  is  presented  in  Section  3. 
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IN  A  WELL-MANAGED  DATA-BASE  ENVIRONMENT,  DATA  ARE  RECOGNIZED  AS 
AN  ORGANIZATION  RESOURCE. 


The  cost -of  data  is  enormous.  In  order  to  separate  the  cost  of 
data  from  other  activities,  it  should  be  managed  directly  and 
separately  from  the  functions  which  use  those  data.  Only  by 
this  management  view  can  the  data  resource  provide  the  greatest 
return  on  its  investment. 

•  DATA  ARE  SUFFICIENTLY  IMPORTANT,  TO  MERIT  SPECIALIZED  AND 
HIGH-LEVEL  MANAGEMENT  ATTENTION 

Many  DLA  organizational  elements  have  data  management  problems 
but  do  not  fully  understand  their  extent.  To  address  these 
problems,  a  high  level  of  management  needs  to  be  involved  in  the 
Data  Strategy.  This  includes  the  perspective  from  DLA 
Headquarters  as  well  as  from  the  CDAs  and  PLFAs  organizational 
levels . 

If  these  Data/Data  Base  environment  principles  are  merely  accepted  by  top 
Management  and  not  committed  to,  the  probability  of  the  success  of  the 
Data  Base  environment  is  greatly  diminished. 


3.2  The  Four  Types  of  Data  Base  Environment 


There  are  four  types  of  data  base  environment  that  are  discernable  in 
DLA.  Each  of  these  types  requires  different  administrative  procedures. 
The  four  types  have  been  listed  in  Exhibit  3-1. 


FOUR  TYPES  OF  DATA  BASE  ENVIRONMENT 


TYPE  I: 
TYPE  II: 
TYPE  III: 
TYPE  IV: 


FILES 

APPLICATION  DATA  BASES 
SUBJECT  DATA  BASES 
MIS  DATA  BASES 


EXHIBIT  3-1 


The  first  type  of  data  base  environment,  files,  contains 
applications  that  utilize  sequential  files,  index  sequential  files  and 
those  applications  where  a  data  base  management  system  is  not  used. 


Exhibit  3-2  describes  TYPE  I  characteristics  in  more  detail. 


TYPE  1  ENVIRONMENT:  FILES 


Separate  files  of  data  are  used  for  most  applications, 
designed  by  the  analysts  and  programmers  when  the 
application  is  created;  a  data-base  management  system  is 
not  used. 

A  large  proliferation  of  files  grow  up  with  high  redundancy 
leading  to  high  maintenance  costs. 

Seemingly  trivial  changes  to  applications  trigger  a  chain 
reaction  of  other  changes  and  hence  change  becomes  slow, 
expensive,  and  is  resisted. 

Example  of  software:  VSAM,  BDAM,  DMS. 

EXHIBIT  3-2 


TYPE  II  ENVIRONMENT:  APPLICATION  DATA  BASES 

A  data-base  management  system  is  used  but  without  the 
degree  of  sharing  in  a  TYPE  III  environment. 

Separate  data  bases  are  designed  for  separate  applications. 

Characteristics:  Easier  to  implement  than  a  Type  III 

environment . 

A  large  proliferation  of  data  bases  grow  up  with  high 
redundancy  like  a  file  environment. 

High  maintenance  costs. 

Sometimes  more  expensive  than  a  TYPE  I  environment. 

Does  not  achieve  the  major  advantages  of  data-base 
operation. 

Examples  of  software:  TOTAL,  IMS,  IDMS,  Honeywell  IDS. 


EXHIBIT  3-3 
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The  TYPE  II  environment  utilizes  data  base  management  system  software 
to  implement  application  systems.  These  systems  may  use  the  DBMS  as  an 
access  mechanism.  The  utilization  of  a  DBMS  in  this  way  can  be 
ineffective  and  inefficient.  Exhibit  3-3  identifies  the  characteristics 
of  this  data  base  environment. 


The  subject  data  base  environment  organizes  the  data  by  real  world 
entities  applicable  to  the  environment.  The  characteristics  of  the 
Subject  data  base  environment  are  illustrated  in  Exhibit  3-4. 


TYPE  III  ENVIRONMENT:  SUBJECT  DATA  BASES 

•  Data-bases  are  created  which  are  largely  independent  of 
specific  applications. 

•  Data-bases  are  designed  and  stored  independently  of  the 
function  for  which  they  are  used. 

•  Data  for  DLA  subjects  such  as  customers,  vendors  or 
personnel  are  associated  and  represented  in  shared 
data-bases. 

•  Examples  of  software:  IMS,  IDMS,  IDS,  ADABAS. 

•  Characteristics:  thorough  data  analysis  and  modeling 

needed,  which  takes  time,  much  lower  maintenance  costs. 

•  Leads  eventually  (but  not  immediately)  to  faster 
application  development  and  direct  user  interaction  with 
the  data  bases . 

•  Requires  a  change  in  traditional  systems  analysis  methods, 
and  in  overall  DP  management. 

•  If  not  managed  well,  it  tends  to  disintegrate  into  a 
TYPE  II  (or  sometimes  TYPE  I)  environment. 


EXHIBIT  3-4 
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The  TYPE  IV  data  base  en'- i ronment ,  MIS  data  bases,  supports  high 
level  management  and  decision-support  functons  and  places  the  power 
of  computers  closer  to  the  users.  In  order  to  accomplish  this  in  a 
efficient  manner,  the  data  base  roust  be  designed  to  permit  what-if 
type  queries.  Separate  hardware  and  a  DBMS  might  be  required  to 
support  the  users  without  impacting  the  production  environment. 
Exhibit  3-5  lists  the  characteristics  of  this  data  base  environment. 

TYPE  IV  ENVIRONMENT:  DATA-BASES  FOR  MANAGEMENT  INFORMATION  SYSTEMS 

•  Data-bases  organized  for  searching  and  fast  information  retrieval 
rather  than  for  high-volume  production  runs. 

•  Employs  software  designed  around  inverted  files,  inverted  lists, 
or  secondary  key  search  methods. 

•  New  data-item  types  can  be  added  dynamically  at  any  time. 

•  Good  end-user  query  and  report  generation  facilities. 

•  Examples  of  software: 

—  IBM's  STAIRS 

—  ICL's  Content  Addressable  File  Store  (CAPS) 

EXHIBIT  3-5 


3.3  Data  Definition 

The  data  manipulated  by  automated  system(s)  needs  to  be  uniquely 
defined  and  preferably  maintained  using  an  automated  tool.  Automated 
tools  are  required  because  of  the  vast  amount  of  metadata  (data  about 
data)  collected  in  an  organization  and  the  need  to  manipulate  the  data 
for  reports,  queries,  and  updating.  The  result  of  uniquely  defining  data 
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is  an  understanding  of  the  amount  of  data  being  collected,  where  it  is 
being  collected  and  how  it  is  being  used. 

3.4  Data  Standardization 

A  follow-on  activity  to  data  definition  is  data  standardization. 
This  activity  identifies  duplicate  data  (synonyms)  and  data  that  has  the 
same  name  but  different  meanings  (homonyms)  given  by  different  users. 
This  effort  reduces  the  costs  of  collecting  data  because  less  data  would 
be  collected  and  will  be  of  greater  consistency  because  the  source  of 
updates  are  controlled. 

The  value  of  the  data  will  be  greater  because  of  its  consistency  and 
accuracy.  This  improves  the  return  on  investment  the  organization  makes 
collecting  and  storing  the  data.  It  also  saves  time  and  effort  because 
it  does  not  collect  and  maintain  duplicate  data. 

3.5  Strategic  Data  Planning 

Strategic  data  planning  is  the  activity  that  reviews  the  enterprise 
and  determines  which  organizations  create  and/or  use  data.  Obviously  the 
metadata  is  of  a  high  level  nature  and  is  functionally  group  together. 
This  planning  informs  top  management  of  the  organizational 
interrelationships  and  supports  the  priority  setting  activity.  In  many 
organizations  it  is  unknown  which  suborganization  is  using  the  data  and 
which  suborganization  is  creating  it  and  takes  responsibility  to  maintain 


it.  Some  organizations  may  be  found  to  be  duplicating  efforts,  that  may 
need  resolution. 

Strategic  Planning  must  also  consider  the  future  information 
requirements  (based  on  its  Business  Plan)  of  the  organization. 
Information  requirements  will  change  as  the  mission  or  objectives  of  the 
organization  change.  Changes  will  be  required  as  the  result  of  changes 
in  governmental  regulations  and  laws.  The  organization  must  forecast 
these  changes  to  anticipate  and  minimize  the  scope  of  change  through 
planning. 

3.6  Logical  Data  Design 

It  is  necessary  to  develop  a  logical  data  model  that  represents  the 
inherent  properties  of  the  data  independently  of  software,  hardware,  or 
machine  performance  considerations.  This  model  presents  the  data  such 
that  it  is  structured  to  evolve  over  time  and  to  minimize  the  application 
software  changes  that  may  be  required.  The  model  is  a  basis  for 
organizing  the  data  into  subject  and  management  information  systems. 

The  logical  design  is  more  detailed  than  the  strategic  plan,  but 
follows  the  strategic  plan  for  the  breakdown  of  functional  or  subject 
categories.  In  this  way  a  "thread"  may  weave  from  the  high  levels  of 
data  to  the  detail  levels. 


This  information  can  be  further  refined  to  illustrate  the  Business 
Units  that  affect  the  enterprises  functional  workload  and  support  the 
estimation  of  computer  hardware  needed.  Business  units  are  key 
transactions  that  can  be  used  to  forecast  the  organization's  work 
volume.  As  the  enterprise  grows,  its  computer  hardware  could  be  acquired 
in  an  orderly  fashion.  This  acquisition  would  be  based  on  the 
organizations  projected  growth  (or  lack  thereof),  such  that  other 
interested  parties  (e.g.,  finance)  may  base  their  supporting  plans. 

3.7  Physical  Database  Design 

The  mapping  of  the  data  to  the  hardware/software  environment  is  the 
function  of  the  physical  database  design.  This  includes  the  physical 
characteristics  of  the  data,  the  specific  mapping  to  the  data  base 
management  system  to  be  used  and  the  access  techniques  necessary  to 
retrieve  and  store  data.  This  function  is  software  and  hardware 
dependent . 

3.8  Support  of  Life  Cycle  Management 

Each  of  these  techniques  is  a  step  towards  automated  systems  and 
provides  the  information  required  to  meet  the  needs  of  DoD  Life  Cycle 
Management  as  represented  by  documentation  outlines  in  DoD  standard  7935. 


3.9  Automated  Tool  Support 

Large  organizations  have  vast  amounts  of  data  that  are  collected, 
maintained  and  used.  In  order  to  manage  metadata  (data  about  data), 
automated  tools  are  beginning  to  be  used.  This  has  developed  into  tools 
that  support  a  given  Life  Cycle  phase  (e.g.,  data  definition,  logical 
data  design).  The  tools  include  data  dictionaries,  logical  data  design 
and  code  generators.  An  organization  must  invest  time  evaluating  these 
tools  and  incorporating  their  use  into  their  manual  procedures.  As 
experience  is  gained  and  the  tools  became  integrated,  their  use  will 
increase  and  their  benefit  will  rise  accordingly. 

The  selection  of  automated  tools  in  todays  environment  is  varied,  but 
the  tools  are  designed  for  specific  life  cycle  phases.  An  integrated  set 
of  tools  does  not  yet  exist  in  the  system  development  environment.  There 
are  three  phases  that  trends  follow  in  the  data  processing  industry.  In 
the  case  of  automated  software  engineering  tool  support,  the  following 
dates  have  been  estimated  by  industry  leaders. 


• 

Phase 

I  -  Crisis  and  Recognition 

1980 

-  1985 

• 

Phase 

II  -  Academic  Emphasis 

1985 

-  2000 

• 

Phase 

III  -  Assimilation  into  Industry 

1990 

-  2020 

Obviously  these  phases  will  overlap  and  may  extend  more  in  particular 
aspects  of  the  industry.  A  fully  integrated  set  of  tools  may  not  exist 
until  the  year  2000. 
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3.9.1  Data  Dictionary/Directories 


Data  dictionaries  are  the  primary  tool  used  by  Data/Data  Base 
Administration  personnel.  They  vary  widely  in  their  capabilities  but 
support  the  following  purposes. 


•  Manage  metadata 

Metadata  (data  about  data)  requires  that  it  be  managed  like 
any  other  resource  within  an  organization.  In  this  way.  the 
organization  can  determine  who  is  collecting  data, 
maintaining  it  and  using  it. 

•  Central  repository  of  data 

The  metadata  should  be  collected  by  organization  elements 
that  collect  or  use  the  data.  The  metadata  should  be 
centrally  managed  and  available  to  the  whole  organization  for 
reference.  This  permits  the  local  organizations  to  refer  to 
the  existing  metadata  for  synonyms  and/or  homonyms  that  may 
exist. 

A  centralized  Data  Dictionary  permits  DLA  Headquarters  to 
control  updates  and  resolve  errors.  This  is  supported  by  the 
fact  that  there  are  not  multiple  DD/D  databases  that  require 
consistency  checks  or  require  multiple  updates. 

•  Enforce  Standards 

Data  Dictionaries  produce  reports  to  support  the  enforcement 
of  standards.  Duplicate  data  objects  or  characteristics  of 
data  objects  can  be  identified  and  flagged  before  they  are 
updated.  The  DD/D  updates  themselves  can  be  limited  to 
selected  users. 

Data  characteristics  can  be  composed  during  design, 
implementation,  and  operation  of  a  computer  system  ensuring 
that  proper  characteristics  (e.g.,  codes)  are  being  used. 
The  enforcement  of  standards  reduces  the  amount  of  updating 
required,  reduces  the  maintenance  of  data  and  permits  the 
interfacing  or  communication  of  data  among  different 
functional  application  systems. 


•  Support  Control  of  Change 


During  the  life  cycle  of  a  system  from  design  to  maintenance, 
Conf iguratipn  Management  impact  analysis  must  be  performed 
before  actual  changes  are  made.  In  this  way  the  number  of 
changes  can  be  anticipated  including  an  estimation  of  the 
resources  required.  A  Data  Dictionary/Directory  can  support 
the  impact  analysis  with  a  query  capability  and/or  standard 
reports.  The  information  provided  these  reports  will  allow 
informed  management  decisions. 

•  Support  the  Analytical  Process 

The  Data  Dictionary/Directory  provides  reports  of  the 
analysis  stat  .s  and  provides  documentation  of  the  analysis. 

The  DD/D  should  support  a  quality  assurance  function.  This 
is  accomplished  by  reports  where  relationships,  descriptions 
or  other  characteristics  are  identified  as  missing.  The 
reports  should  be  capable  of  providing  a  top-down  or  a 
bottom-up  view.  Where  necessary  references  to  manual 
documentation  and/or  system  requirements  can  be  provided  to 
assist  the  quality  assurance  effort. 

Documentation  is  capable  of  being  presented  according  to  the 
intended  audience.  Information  to  the  analysts  and 
operational  users  (acting  as  reviewers)  may  contain  greater 
detail  as  compared  to  reports  for  higher  level  managers. 
Flexibility  is  a  key  capability  needed  to  focus  the  required 
information  in  a  preferred  format  for  discussion/ review. 


Data  Dictionary/Directories  are  one  of  two  types;  Passive  or  Active. 
Passive  DD/Ds  are  stand  alone  systems  that  may  or  may  not  be  dependent  on 
a  Data  Base  Management  System  (DBMS).  In  either  case,  metadata  is 
captured  and  stored  for  most  methodologies  and  DBMSs.  Passive  DD/Ds  can 
be  manual  (e.g.,  card  index),  automated  and  developed  in-house  (e.g.,  DLA 
MSS)  or  a  commercial  package  (e.g.,  PSL/PSA) . 


Active  DD/Ds  are  not  active  per  se,  but  are  highly  coupled  with  a 
given  DBMS.  The  DD/D  provides  the  schemas  and  subschemas  for  compilation 
by  the  DBMS.  Some  DD/Ds  will  also  provide  the  data  definition  to 
language  compilers  at  compilation  time  for  programmers.  In  this  way  the 
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DD/D  has  greater  control  regarding  the  changes  to  both  schemas  and  data 
definitions  (i.e.,  the  changes  must  be  made  through  the  data 
dictionary).  The  changes  are  automatically  provided  to  the  application 
programs.  Features  of  passive  and  active  DD/D  are  discussed  in  detail  in 
Section  4. 

3.9.2  Bridges  to  Other  Automated  Tools 

The  effectiveness  of  automated  tools  is  greatly  enhanced  when  the 
data  can  be  transferred  electronically  (e.g.,  telecommunications, 
magnetic  tape.  disk).  In  this  way  the  data  can  be  manipulated  by  humans 
through  multiple  software  packages.  As  data  is  transferred  from  one 
process  to  another,  quality  assurance  checks  and  audit  trails  can  be 
executed  and  confirmed.  Due  to  the  volume  of  data,  the  quality  assurance 
procedures  would  probably  not  be  executed  in  a  manual  mode  considering 
the  amount  of  time  required  to  complete  the  task.  Bridges  provide  the 
means  to  integrate  stand  alone  tools  to  support  the  full  system  life 
cycle. 

3.9.3  Other  Support  Tools 

In  this  section  we  discuss  other  tools  that  support  the  D/DBA  area. 
Unfortunately,  some  of  these  tools  are  integrated  together  and  others  are 
highly  coupled.  This  implies  that  certain  products  are  capable  of 
executing  with  a  given  DBMS,  specific  hardware  family,  or  require  unique 
data  formats.  These  tools  are  presented  by  the  D/DBA  areas: 


•  Logical  Data  Modeling 

There  are  automated  tools  that  input  the  data  relationships 
(preferably"  through  a  bridge  with  a  data  dictionary)  and 
synthesizes  the  optimal  third-normal-form  structures, 
documents  the  structures  and  assists  with  data  base  design. 
The  output  also  serves  as  a  corporate-wide  data  model. 

•  Physical  Database  Design 

Some  DBMS  products  offer  a  tool  to  assist  in  selecting  access 
methods,  determining  hardware  requirements  and  physical  data 
layout.  These  tools  assist  the  data  base  designer  to  develop 
the  optimum  data  base  design. 

•  Machine  Performance 

There  are  a  number  of  products  available  that  measure  the  CPU 
utilization,  memory  usage,  channel  and  access  mechanisms. 
These  products  are  designed  for  specific  computer  families 
and  may  not  be  available  for  some  computers.  The  computer 
manufacturer  or  an  independent  vendor  could  supply  these 
measurement  products. 

There  is  another  set  of  products,  referred  to  as  monitoring 
aids  that  measure  input  volumes  from  end  users  (i.e.. 
Business  Units),  types  of  transactions,  response  times  and 
rates  of  growth.  The  DLA  ORACLE  project  is  working  towards 
one  such  product.  Prototyping  of  software  also  would  provide 
similar  information  that  would  affect  the  design  of  the 
actual  software.  Prototyping  tools  are  based  on  very  high 
level  languages  and  can  be  configured  to  emulate  the  proposed 
software  environment. 


Since  the  automated  tools  are  usually  stand  alone  packages,  the  Database 
Administrator  may  have  to  sponsor  the  development  of  specific  bridges  for 
the  tools  he  has  acquired. 


SECTION  4.  GENERAL  DESIGN  FRAMEWORK 


In  the  previous  sections  we  provided  a  brief  summary  of  DLA's 
current  D/DBA  administration  environment.  We  highlighted  key 
findings  and  issues  relative  to  that  environment.  We  also  indicated 
some  basic  principles  for  effectively  managing  a  D/DBA  environment. 

In  this  section  we  will  describe  a  general  design  framework  for 
establishing  an  effective  D/DBA  administration  program.  This  design 
framework  has  three  dimensions. 

•  What  functions  have  to  be  performed  to  effectively  manage  the 
D/DBA  environment  in  DLA? 

•  What  tools  are  needed  to  support  the  functions? 

•  Where  should  the  functions  and  tools  be  located  throughout 
DLA? 

These  dimensions  support  the  three  primary  data  representations 
outlined  in  Exhibit  4-1.  The  Logical  Model  represents  data  as 
viewed  by  management.  At  its  composite  level  (i.e.,  data  entities) 
and  at  the  lower  levels  as  viewed  by  users  (e.g.,  elements).  The 
software  schemas  represent  the  relationships  among  the  data 
entities.  Physical  Data  Base  design  includes  the  physical  mapping 
of  the  data  and  the  associated  overhead  to  a  particular  DBMS. 

Subsequent  paragraphs  discuss  the  required  functions  and  tools 
while  Section  5  discusses  the  proposed  organizational  structure. 
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4.1  Required  D/DBA  Functions 


There  are  five  major  functions  that  should  exist  in  an 
organizations'  Data/Data  Base  Administration  environment.  In  some 
organizations  these  functions  may  be  combined  and  performed  by  one 
individual  primarily  depending  on  the  organization  size  and 
disbursement  of  business  functions.  These  are: 

•  Data  Strategy  Planning 

•  Data  Administration 

•  Data  Base  Administration  and  Design 

•  Data  Distribution  Administration 

•  Auditing  and  Security. 

Each  of  these  major  functions  contributes  to  the  overall  Data/Data 
Base  Administration  effort.  The  following  sections  explain  the 
individual  functions  in  detail  and  provide  insight  on  how  they  interface. 

4.1.1  Strategic  Data  Planning 

The  purpose  of  this  function  is  to  develop  a  corporate  view  of  data 
considering  how  data  is  used  today  and  how  it  should  be  used  tomorrow. 
In  order  to  accomplish  these  tasks  the  individual  performing  this  task 
must  work  both  with  the  functional  user  management,  data  processing 
management,  and  corporate  management.  This  responsibility  requires  that 
the  data  strategy  function  educate  the  functional  and  corporate  managers 
as  to  the  importance  of  data  planning  and  to  emphasize  the  benefits  to 
all  participants. 
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STABILITY  ANALYSIS  STEPS 


Confirmation  of  Associations  (relationships)  among  -^'ta 
entities.  The  associations  include  one  to  one,  one  to  many  and 
many  to  many  relationships. 

Confirmation  of  Data  element  identification  and  definition  with 
users  to  ensure  that  standards  are  being  followed  and  that  all 
appropriate  users  have  had  an  opportunity  to  participate. 

Determination  whether  data  elements  may  become  a  key  in  the 
future.  Industry  trends  may  require  that  users  view  data 
differently  then  today. 

Confirm  whether  identified  keys  are  accurately  stated. 

Determine  the  cardinality  of  each  Association  by  review  with 
users  and  comparison  with  existing  systems. 

Identify  the  usage  path  and  the  expected  volumes  (i.e.,  low, 
high,  mean).  Identified  Business  Units  will  provide  the 
expected  volumes  across  future  time  periods. 

Compare  usage  path  volumes  and  determine  whether  expected 
response  will  be  acceptable,  depending  on  the  audience  of  the 
system  and  the  level  of  organization  it  supports. 
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CANONICAL  SYNTHESIS  STEPS 


1.  User  views,  or  subschemas  are  extracted  from  the  functional 
requirements  in  a  form  amendable  for  further  manipulation.  In 
general,  the  important  user  view  information  to  be  extracted  include: 

Primary  key  items 

Secondary  key  items 

Concatenated  primary  keys 

Functional  dependencies  among  items. 

2.  A  validation  of  user  view  data  against  the  data  dictionary  are  made 
in  order  to  ensure  that  correct  element  and  view  names  and 
descriptors  have  been  extracted. 

3.  An  automated  package  (e.g..  Data  Designer)  or  a  manual  process  will 
next  combine  the  set  of  user  views  using  the  process  of  canonical 
synthesis . 


Basically,  this  process  involves  a  three  step  normalization  process: 
First  Normal  Form:  Internal  repeating  groups  are  removed 


Second  Normal  Form:  All  improper  functional  dependencies 

between  keys  and  attributes  are  removed 

Third  Normal  Form:  All  improper  functional  dependencies 

between  non-key  attributes  are  removed. 

The  end  result  of  the  normalization  process  is  a  non-redundant  data 
structure,  free  of  transitive  dependencies. 


4.  Following  the  generation  of  a  canonical  form  logical  data  base 
design,  it  is  important  that  it  be  reviewed  carefully  with  the 
functional  proponents  and  evaluated  for  consistency  with  the  baseline 
Functional  Definition  requirements.  The  iterative  design  process  may 
then  continue  by  once  again  using  an  automated  tool  or  the  manual 
algorithms  to  generate  a  new  logical  data  base  design. 


5.  The  final  steps,  following  the  synthesis  of  the  optimal  data  base 
design,  will  be  the  integration  of  the  design  parameters  into  the 
functional  documentation. 


EXHIBIT  4-8 
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Exhibit  4-8  documents  the  steps  involved  in  Canonical  Synthesis. 

4. 1.2. 5  Coexistence  Design 

A  determination  must  be  made  as  to  which  data  should  remain  in 
sequential  files,  application  data  bases  (TYPE  II)  and  those  that  should 
be  converted  to  Subject  Data  bases  (TYPE  III).  The  planning  and  timing 
of  any  conversions  should  be  calculated  and  coordinated  with  the  Data 
Base  Administrators/Designers,  user  group(s)  and  management. 

4. 1.2. 6  Stability  Analysis 

This  function  is  responsible  for  determining  whether  the  data 
model  reflects  our  current  environment  and  if  it  will  address  any 
future  requirements  that  we  can  identify  today.  The  importance  of 
this  function  is  to  refine  the  data  model  such  that  application 
programs  can  be  developed  that  assume  the  data  model  truly  reflects 
user  requirements.  Exhibit  4-9  identifies  the  steps  for  Stability 
Analysis . 


The  selection  of  a  passive  or  active  Data  Dictionary  depends  on  the 
organization  environment  and  its  future  plans.  The  Data  Strategist  and 
Data  Base  Administrator/Designer  should  participate  on  the  decision  on 
the  choice  of  software.  Exhibit  4-7  lists  some  considerations  that 
should  be  addressed. 


DD/D  SELECTION  CONSIDERATIONS 


•  Choice  of  dictionary  presents  problems  in  a  multiple  DBMS 
environment 

•  Usually  a  compromise  is  to  use  the  dictionary  of  the  most 
widely  used  DBMS  (such  as  TIS  in  DLA) 

•  Choice  of  dictionary  and  the  facilities  which  link  to  it  need 
to  be  a  part  of  the  Strategic  Top-Down  Data  Planning 


EXHIBIT  4-7 


4. I. 2. 4  Canonical  Synthesis 

This  function  creates  independent  Data  Models  of  application 
systems.  It  is  important  that  the  physical  design  be  built  on  a  logical 
foundation  to  meet  the  user  requirements  for  data  access.  This  will 
minimize  the  impact  to  the  data  base  structure  resulting  from  changes  in 
the  organization. 

Data  Base  Management  System  technology  has  received  a  poor  review 
because  organizations  have  not  received  the  expected  benefits  from  them. 
In  some  cases,  any  of  the  performance/cost  benefits  have  been  worse  than 
sequential  files.  This  was  the  result  of  poorly  coupled  data  and  its 
dependency  on  applications. 


Passive  DD/D  Features 


•  Supports  Definition  of  all  types  of  data  items,  data 
grouping,  and  data  associations. 

•  Permits  Aliases  (Synonyms)  to  be  recorded,  and  indicates 
where  one  data  item  is  really  the  same  as  another  which 
(for  historical  reasons)  may  be  represented  differently. 

•  Permits  homonyms  to  be  recorded  (different  data  items 
that  have  been  given  the  same  name  on  different 
projects)  and  indicates  on  which  projects  they  are  used. 

•  Provides  support  for  different  types  of  DBMS  so  that  a 
multiple-DBMS  environment  can  be  supported. 

•  Supports  the  definition  of  process  entities  (e.g., 
systems,  programs,  modules,  projects,  transactions) 

•  Supports  the  definition  of  usage  entities  (e.g.,  users, 
terminal,  department,  company) 

•  Prints  attractively  formatted,  easily  comprehensible 
reports  of  all  aspects  of  dictionary  usage. 

•  Provides  KWIC  (key  word  in  context)  indices  to  help  in 
searching  for  information  in  the  dictionary. 

•  Supports  the  definition  of  security  levels  and 
authorization  details. 

•  Supports  distributed  data-base  systems,  showing  what 
data  are  kept  at  each  location,  and  what  type  of 
distribution  is  used  (e.g.,  replicated  data,  partitioned 
data) 


EXHIBIT  4-6 
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Active"  DD/D  Features 


•  Enforces  the  use  of  data  definitions  that  are  in  the 
dictionary 

•  Selective  Enforcement;  Enforces  the  use  of  dictionary 
definitions  for  some  projects  and  not  others 

•  Automatically  converts  data  items  to  the  same  formats 
before  adding  or  otherwise  manipulating  them  in 
combination 

•  Sharing  of  dictionary  and  DBMS  tables  for  operational 
efficiency 

•  Integration  of  the  dictionary  with  the  DBMS  user 
languages  and  sometimes  direct  interaction  with  the 
language  user 

•  Used  in  the  interpreter  or  compiler  of  database  languages 

•  Inserts  labels  of  data  items,  columns,  or  chart  axes 
into  reports  generated  by  users 

•  Enforcement  of  auditor's  rules 

•  Support  the  distribution  of  data  which  enables  one 
machine  to  locate  and  utilize  data  that  reside  in 
different  machines 


EXHIBIT  4-5 
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4. 1.2. 3.1  Selection  of  Data  Dictionary/Directory  Software 


Obviously, 

the 

DD/D  software 

will  have 

to 

be  executed  on 

the 

available  hardware 

and  both  the 

hardware 

and 

software  should 

be 

configured  to 

handle  the  expected 

volumes . 

If 

the  organization 

is 

dispersed  throughout  the  country,  multiple  software  configurations  may  be 
required;  one  for  each  location.  Procedures  would  be  developed  to 
transfer  metadata  to  the  various  sites.  Audits  would  be  necessary  to 
ensure  maintenance  compliance. 

Probably  the  most  important  decision  to  be  made  is  whether  the  DD/D 
should  be  an  Active  DD/D  or  a  Passive  DD/D.  An  Active  DD/D  is  usually 
highly  coupled  with  a  Data  Base  Management  System.  Its  advantages 
include  the  enforcement  of  standards  and  the  automatic  interfacing 
between  the  DBMS  and  the  DD/D,  The  features  of  an  Active  DD/D  are 
illustrated  in  Exhibit  4-5. 

A  passive  DD/D  is  a  stand  alone  package  that  is  not  highly  coupled 
with  a  DBMS,  but  supports  the  methodology(  ies )  used  in  an  organization 
and  provides  the  necessary  analytical  and  documentation  reports.  The 
features  of  a  Passive  DD/D  are  included  in  Exhibit  4-6. 
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The  data  element  standards  must  be  developed  from  a  corporate 
perspective  and  distributed  throughout  the  organization.  These  should  be 
reviewed  by  all  Data  Administrators  every  few  years.  In  this  way,  there 
should  be  little  disagreement  over  the  standards  selected  and  they  should 
be  adhered  to. 

If  the  situation  regarding  a  data  element  identification  involves 
synonyms  and/or  homonyms  and  it  cannot  be  resolved  at  the  lower 
organization  levels;  the  corporate  Data  Administrator  will  have  the 
authority  to  determine  the  final  outcome.  The  various  parties  should  be 
encouraged  to  resqlve  the  situation. 

4. 1.2. 3  Maintenance  of  Data  Dictionary/Directory( ies) 

The  Data  Administration  function  is  responsible  for  the  following 
activities  regarding  Data  Dictionary/Directories: 

•  Selection  of  Data  Dictionary/Directory  software 

•  Manage  the  operation  and  maintenance  of  the  DD/D  software, 

•  Develop  and  manage  "bridges"  between  DD/D  in  different 
locations  and  among  different  automated  tools  (e.g.,  DD/Ds 
and  logical  design  tools) 

•  Develop  and  audit  compliance  of  DD/D  usage  and  reference  by 
all  parties  involved 

•  Develop  procedures  and  forms  for  the  gathering  of  metadata 
and  its  report  generation. 

These  activities  are  discussed  in  detail  below; 


4. 1.2.1  Logical  Data  Modeling  and  Validation 

This  function  is  responsible  for  the  data  organization  reflecting  its 
inherent  nature.  This  organization  takes  into  account  individual 
functions  and  subject  area  factors.  The  Data  Administrator  works  very 
closely  with  the  Data  Strategist  in  developing  these  models  to  ensure 
that  the  high  level  view  is  consistent  with  the  organizations  long  term 
plans.  The  logical  data  model  is  independent  of  any  hardware  or 
software.  The  Data  Strategist  will  provide  and  coordinate  input  to  the 
Data  Administration  function. 

4. 1.2. 2  Data  Element  Analysis  and  Standardization 

This  function  is  responsible  for  the  identification  and  definition  of 
data  elements  and  their  logical  grouping.  Data  element  definition  will 
occur  with  the  Data  Administrators  located  with  the  design  agencies. 
During  this  process,  the  design  agency  Data  Administrator  will  reference 
existing  data  element  standards. 

The  Data  Administrator  for  the  headquarters  organization  will  review 
the  data  elements  being  identified  to  ensure  that  synonyms  and  homonyms 
are  eliminated.  Synonyms  are  data  elements  that  have  different  names  but 
the  same  meaning.  Homonyms  are  data  elements  that  have  different 
meanings  but  the  same  name.  Also  as  part  of  this  function,  the  Data 
Administrator  will  review  data  element  definitions  to  ensure  consistency 
with  applicable  standards  (e.g.,  naming  conventions). 


DATA  ADMINISTRATION  FUNCTION 


•  Logical  Data  Modeling  and  Validation 

Individual  Functional  or  Subject  Area  Perspectives 

•  Data  Element  Analysis  and  Standardization 

-  Identify  Data  Element  Definitions  and  Naming 
Conventions  (e.g..  Synonyms) 

Standardize  as  appropriate 

•  Maintenance  of  Data  Dictionary/Di  rectory ( ies ) 

•  Canonical  Synthesis 

Creates  software  independent  data  model (s) 

Describes  the  inherent  nature  of  the  data 
Third  normal  form 

•  Coexistence  Design 

Determines  whether  'flat'  files  or  application  data 
bases  should  be  converted  to  subject  data  bases 

Plans  the  bridge  for  the  conversion 

•  Stability  Analysis 

Forces  the  organization  to  think  about  past  and  future 
uses  of  data 

•  Selection  of  Data  Dictionary/Directory  and  Logical  Data 

Modeling  Tools 

•  Development  of  Automated  Support  Standards 


EXHIBIT  4-4 
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,  DATA  STRATEGY  PLANNING  FUNCTION 


DLA  Wide  Planning  Data 

-  High  Level  View  -  Enterprise  Model 
Functional  Area  Views 
DLA  Wide  Data  Resource  Plan 

Identifies  who  are  the  'Owners’  of  data  and  who  are 
the  'Users'  of  data 

Assessment  of  Future  Information  Requirements 

Development  of  an  Entity-Relationship  Overview  Chart 

Clustering  Entities  into  Subject  Data  Bases 

Provides  an  Independent  View  of  How  Existing  Systems 

Interact  with  the  Business  Functions 

Identifies  what  Data  is  Utilized  by  Which  Systems 

Handling  of  Human  and  Political  Problems  in  the 

Establishment  of  Common  Data  Throughout  the  Enterprise  DLA 

Education  of  top  management  in  the  need  for  strategic 
planning  of  data  and  enforcement  of  common  data  definitions 
and  models 

Requires  a  high  level  steering  committee  and  a  separate 
data  strategist  position. 

Performs  DLA  Wide  data  planning 

Assesses  DLA  future  information  requirements 

Develops  an  entity-relationship  overview  chart  for  DLA 

Clusters  Entities  into  special  data  bases 

Handles  human  and  political  problems  in  the  establishment 
of  common  data  throughout  DLA 


EXHIBIT  4-3 
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This  function  is  very  political  in  many  respects,  having  to  seek  the 
cooperation  of  functional  and  corporate  managers  while  "teaching"  them 
how  their  business  operates.  Many  of  these  managers  would  be  justifiably 
insulted  if  some  people  thought  that  they  did  not  know  their  business. 
It  would  be  very  helpful  to  this  function,  if  the  Data  Strategist 
reported  to  the  chief  organization  officer.  This  would  provide  the  "Top 
Management"  backing  to  effectively  implement  this  function. 


Once  the  Strategic  Data  Model  has  been  developed,  it  feeds  the 
Logical  Data  Model  and  Physical  Data  Model  development.  Exhibit  4-2 
illustrates  the  relationship  between  the  Strategic  Data  Model  and 
subsequent  data  models. 


Exhibit  4-3  presents  the  overall  Strategic  Planning  function. 


4.1.2  Data  Administration 


Data  Administration  is  responsible  for  the  designing  of  data 
models  for  the  organization.  The  data  models  are  relevant  to  the 
specific  organization  levels  for  which  they  were  developed.  This 
involves  the  coordination  amongst  the  various  levels  of  the 
organization  and  a  set  of  procedures  to  bridge  the  data  among  the 
tools  supporting  the  Data  Administrators 


Exhibit  4-4  illustrates  the  Data  Administration  functions. 
These  are  discussed  in  detail  below. 
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4.1.2. 7  Development  of  Automated  Support  Standards 

To  effectively*  utilize  the  automated  tools  in  the  Data  Administration 
function,  standards  must  be  designed  to  interface  the  organization 
methodologies  with  the  tools.  In  this  way  the  metadata  will  be 
collected,  coded  and  reported  consistently  regardless  of  the  application 
or  location.  The  standards  should  be  developed  by  a  central  headquarters 
group  and  used  by  all  Data  Administrators  throughout  the  organization. 
The  headquarters  Data  Administration  group  should  conduct  periodic 
reviews  and  audits  to  ensure  that  the  standards  are  being  followed. 
Exhibit  4-10  identifies  areas  of  standards  that  should  be  developed. 

AREAS  OF  AUTOMATED  SUPPORT  AREAS 

•  Naming  Conventions 

•  Standard  Abbreviations  and  Acronyms 

•  Relationship  Utilization 

•  Bridge  Formats  and  Standards 

•  Report  and  Report  Parameter  Utilization 

•  Data  Entry 

•  Quality  Assurance 

•  Backup 

•  MetaData  Distribution 

•  Synonym  and  Homonym  Discrepancy  Resolution 
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Although  these  standards  should  be  centrally  controlled,  suggestions 
for  change  should  be  encouraged  from  the  field  and  seriously  considered 
by  management;  all  suggestions  should  be  formally  responded  within  thirty 
days  as  to  its  acceptance,  rejection,  and/or  current  consideration. 

4.1.3  Data  Base  Administration/Design 

The  Data  Base  Administrative/Design  function  is  responsible  for  the 
physical  design  of  data  bases.  Data  Base  Management  System(s)  and  its 
environment.  In  many  respects  this  function  has  greater  technical 
aspects  than  does  the  Data  Administration  function. 

The  Data  Base  Administration  function  must  coordinate  with  the  Data 
Administration  function  regarding  the  transition  between  the  logical  data 
model  and  the  physical  data  model.  In  addition.  Data  Base  Administration 
will  have  to  deal  with  the  programming  staff  regarding  the  data  base 
design,  access  techniques  and  appropriate  standards.  Exhibit  4-11 
identifies  the  Data  Base  Administration/Design  Functions.  These 
functions  are  discussed  in  detail  below. 

4. 1.3.1  Data  Base  Software  Evaluation  and  Selection 

The  selection  of  Data  Base  Management  System  software  is  a  difficult 
decision  because: 

•  Its  a  major  investment  in  terms  of  system  support 

•  Staff  training  is  more  complex 


Whatever  DBMSs  are  chosen,  it  is  best  to  minimize  the  number  of 


packages  operational  within  the  organization.  Exhibit  4-12  lists  reasons 
why  the  fewer  DBMSs  within  an  organization  are  to  its  advantage. 


DATA  BASE  ADMINISTRATION/DESIGN  FUNCTIONS 

•  Data-Base  Software  Evaluation  and  Selection 

•  Determine  Data-Base  Standards  and  Design  Techniques 

•  Design  of  Data  Base  Schemas 

-  Uses  Logical  Data  Models  as  Input 

-  Uses  Automated  Data  Dictionary 

•  Physical  Data  Design 

•  Independent  File  Design 

•  System  Integrity/Recovery  Planning 

•  Performance  Analysis 

•  Data  Base  Conversion  Planning 

•  Software  development  is  more  complex 

•  Ability  to  support  the  long  term  organizational  requirements 
requires  more  planning 

•  Different  DBMSs  are  best  suited  to  specific  application  types. 

•  Data  Base  Software  Evaluation  and  Selection 

•  Determine  Data  Base  Standards  and  Design  Techniques 

•  Design  of  Data  Base  Schemas 

-  Uses  Logical  Data  Models  as  Input 

-  Uses  Automated  Data  Dictionary 

•  Physical  Data  Base  Design 
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DATA  BASE  ADMINISTRATION/DESIGN  FUNCTIONS 


•  Independent.  File  Design 

•  System  Integrity/Recovery  Planning 

•  Performance  Analysis 

•  Data  Base  Conversion  Planning 

/ 

EXHIBIT  4-11  (continued) 

Advantages  to  Fewer  Operational  DBMSs  in  an  Organization 

•  Less  DBMS  software  maintenance 

•  Fewer  standards  to  be  developed,  maintained  or  need  enforcement 

•  The  amount  of  training  and  cross  training  of  personnel  that  is 
required 

•  Fewer  data  manipulation  routines  that  have  to  be  developed  and 
maintained 

•  Greater  control  of  data  with  data  dictionary  Support 

EXHIBIT  4-12 


More 

than  one 

DBMS  may  be 

required  to 

support  an 

organization 

depending 

on  user 

requirements . 

Operational 

users  may 

require  the 

ability 

to  select 

a  customers 

record  very 

quickly; 

while  higher 

management  may  require  a  sophisticated  query  capability  to  analyze 
trends.  Exhibit  4-13  illustrates  information  characteristics  by  Area  of 
Management  decision. 

In  order  to  provide  for  expected  response  times  from  the  variety  of 
users,  it  may  be  necessary  to  locate  the  data  on  a  separate  hardware 
configuration.  The  analysis  to  determine  the  location(s)  of  data  should 
be  performed  by  the  Data  Distribution  function  described  below  in  this 


document . 


ADP  CAPABILITY  BY  MANAGEMENT  AREA 


Data 

Characteristic 


Strategic  Management 

Planning  Control 


Accuracy 
Level  of  detail 
Time  horizon 
Frequency  of  use 
Source 

Scope  of  information 
Type  of  information 
Age  of  information 


Low 

Aggregate 

Future 

Infrequent 

External 

Wide 

Qualitative 

Older 


ADP  Capability 


Scheduled  demand 


SLOW-REACTION 

INFORMATION 

SYSTEM 


COMPLEX 

OFF-LINE 

QUERIES 


GENERALIZED 

Unscheduled  demand  INFORMATION 

SYSTEM 


COMPLEX 

ON-LINE 

QUERIES 


Operational 

Control 

High 

Detailed 

Present 

Frequent 

Internal 

Narrow 

Quantitative 

Current 


PRODUCTION 
DATA  PROCESSING 


SIMPLE 

QUERIES 
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4. 1.3. 2  Data  Base  Standards  and  Design  Techniques 


This  function  is  responsible  for  establishing  standards  relating  to 
the  DBMS{s)  selected  for  the  organization.  Standards  must  be  developed 
for  updating  data  base  records,  recovery,  and  access  strategies.  Design 
techniques  will  require  standards  to  ensure  the  integrity  of  the 
operational  data  bases. 


4. 1.3. 3  Design  of  Data  Base  Schemas 


Once  the  logical  data  model  has  been  created,  it  is  necessary  to 
create  a  logical  schema  model.  The  logical  schema  model  is  independent 
of  the  DBMS  or  other  software  considerations. 
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Data  Base  Schemas  are  represented  using  Entity  Modeling.  An  entity 
is  a  real  world  object  (e.g.,  person,  place  or  thing)  which  we  store 
data.  In  the  DLA  environment  an  materiel  item  is  an  entity.  Entities 
are  described  by  their  attributes  (i.e.,  data  elements).  Each  attribute 
is  given  a  name  and  description.  Attributes  may  be  identified  as  the 
"key"  or  primary  index  for  an  entity.  If  an  attribute  is  not  "key"  it 
must  be  dependent  on  a  key. 

Entities  are  associated  with  one  another  by  relationships.  The 
relationships  are  provided  names  which  may  indicate  some  meaning  and/or 
the  directionality  of  the  relationship. 


There  are  other  characteristics  identified  to  relationships  among 
entities.  They  include: 


•  Associativity/Exclusivity  -  indicates  the  degree  of  association 
(e.g.,  one  to  many,  one  to  one,  many  to  one,  many  to  many)  between 
objects.  The  Associativity  may  also  be  expressed  as  a 
cardinality  (e.g.,  1:3,  10:10). 

•  Optional  -  The  entity  may  have  an  optional  existence  and  if  an 
entity  did  not  exist,  the  relationship  would  not  exist. 

•  Contingent  -  The  existence  of  an  entity  is  dependent  on  the 
relationship. 

•  Conditional  -  The  existence  of  one  of  the  entities  is  dependent  on 
a  outside  factor. 

•  Mandatory  -  The  existence  of  the  entities  is  mandatory. 

•  Environmental  constraints  -  The  relationships  may  be  restricted 
further  by  outside  (environmental)  factors. 


The  logical  data  design  could  be  considered  complete  upon  the 
identification  of  the  entity-relationship  model.  Many  data  dictionaries 


permit  the  analyst  to  manipulate  the  entities  and  relationships  with 
greater  efficiency  and  effectiveness. 


4. 1.3. 4  Physical  Data  Base  Design 

This  function  is  responsible  for  the  actual  Data  Base  design 
considering  the  hardware  and  software  characteristics.  During  this 
activity  the  logical  data  base  schema  is  translated  into  the  data 
definition  language  of  the  DBMS  being  used.  The  following  steps  are  used 
to  develop  the  physical  design. 


•  Physical  record  format  -  This  activity  addresses  the 
requirements  of  redundancy,  derived  versus  explicitly  stored 
values,  and  data  compression. 

•  Physical  Record  Clustering  -  This  activity  is  responsible  for 
determining  the  allocation  of  different  record  types  into 
physical  clusters  to  take  advantage  of  the  disk  read/write 
characteristics,  (e.g.  via  relationship  of  CODASYL  databases). 

The  mapping  of  physical  records  to  blocks  is  also  determined 

during  this  activity.  A  physical  block  is  a  fixed  amount 

(the  amount  may  vary  by  manufacturer)  of  information  read  or 
written  with  each  input/output  request. 

•  Develop  Access  Method  Techniques  -  This  activity  is 
responsible  for  developing  access  techniques  for  application 
searches.  Most  searches  will  be  on  the  identified  keys  (in 
the  logical  schema)  to  find  the  physical  records.  There  is 
DBMS  overhead  with  any  physical  structure,  therefore  it  is  a 
prime  objective  to  minimize  this  overhead  while  achieving  the 
required  access  paths. 

•  DBMS  Routine  Program  Design  -  In  order  to  reduce  initial 

programming  costs  and  subsequent  maintenance,  standard  DBMS 
routines  should  be  design  for  the  access  paths  identified 
above.  During  this  phase  design  decisions  must  be  made 
regarding  buffer  areas  and  operating  system  parameters. 
These  are  hardware  specific  decisions  and  cannot  be  generally 
stated. 
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4. 1.3. 5  Independent  File  Design 


Independent  file  design  consists  of  those  activities  that  are 
necessary  to  develop  a  physical  record  layout  for  sequential  files  and 
the  physical  characteristics  of  the  file  itself.  Record  layout  design  is 
composed  of  the  activities  of  Data  Item  Representation  and  Compression. 

The  Data  Item  Represent -tion  techniques  usually  found  on  most 
machines  are: 


•  Position  7  Fixed  length  fields  for  item  values  that  permits 
efficient  software  and  unused  storage  space. 

•  Relational  -  Substitutes  a  special  character  for  a  string  of 
blanks.  Associated  with  the  special  character  is  a  cardinality 
representing  a  repetitive  factor.  This  approach  assumes  that  the 
special  character  will  not  be  elsewhere  in  the  data  file. 

•  Index  -  This  type  of  representation  may  take  various  forms.  The 
Index  may  contain  the  starting  location  of  a  field  or  may  indicate 
whether  the  field  values  are  present  or  not. 

•  Labelled  -  Each  field  value  is  preceded  by  the  field's  name.  The 
fields  may  be  in  any  order  and  if  there  is  no  value,  there  will  be 
no  associated  name. 

•  Free-format  -  The  fields  are  separated  by  a  special  character 
(e.g.,  a  comma).  If  there  is  no  value  for  the  field,  two 
separator  characters  are  concatenated  together. 


Compression  is  a  method  for  conserving  space  on  secondary  storage. 
Compression  techniques  include: 


•  Abbreviations  -  These  permit  the  substitution  of  a  few  characters 
for  many  (e.g.,  NY  for  New  York).  Depending  on  the  number  of 
values  and  functional  objectives,  this  translation  may  be  done 
manually  or  via  automated  mechanisms. 


•  Null  suppression  -  This  technique  is  used  to  suppress  blanks  and 
zeros  in  data  files  that  contain  a  relatively  large  number  of  this 
type  of  data. 

•  Pattern  Substitution  -  Provides  for  the  selection  of  one  character 
for  many  characters  in  a  file.  Obviously  the  substitution  must  be 
consistent  throughout  the  file. 


Independent  file  design  also  includes  the  determination  of  the 
following  factors: 


•  Type  of  Application  -  An  indication  of  online/offline,  retrieval 
only  or  update  and  retrieval  or  sequential/random  processing. 

•  Sort  Order  -  Sorting  of  records  may  be  avoided  if  the  file  is 
sorted. 

•  Blocking  Factor  -  Depending  on  the  availability  of  memory,  greater 
input/output  accesses  can  be  reduced  to  meet  a  particular  projects 
requirements . 

•  File  Size  -  The  cardinality  of  records  will  affect  processing  and 
performance. 

•  Loading  Factor  -  Plans  ahead  for  growth  of  the  file;  permits  a 
smooth  transition  if  a  data  file  reorganization  takes  place. 

•  Search  Mechanism  -  Whether  most  reports  and/or  updates  are  to 
individual  records  or  multiple  records  at  one  time. 


The  activities  to  accomplish  independent  file  design  are  similar  to 
those  of  a  Data  Base  Management  System.  They  are  not  crucial  in  a 
sequential  environment,  but  if  not  performed  property  will  cause 
unnecessary  burdens  on  the  computer  hardware. 


4. 1.3. 6  System  Integrity/Recovery  Planning 

The  Data  Base  designer  must  provide  for  the  planning  of  the  integrity 
of  the  data  base  to  ensure  that  the  data  collected  has  value  to  the 
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INTEGRITY  PROBLEMS 


•  Field  Definition  -  Various  parts  of  an  organization  have  different 
definitions  (hononyms)  regarding  the  same  data  or  have  different 
names,  but  have  the  same  meanings  (synonyms). 

•  Field  Structure  -  The  characteristics  (e.g.,  size,  codes)  of  a 
data  field  varies  within  the  organization. 

•  Record  Structure  -  Records  identified  with  the  same  key  have 

different  attributes  within  the  organization. 

•  Update  Intervals  -  The  updating  frequencies  (e.g.,  weekly)  differ 
within  the  organization,  therefore  managers  cannot  understand  the 
discrepancy  in  the  data  values. 

EXHIBIT  4-14 

organization.  Exhibit  4-14  illustrates  the  areas  that  integrity  problems 
may  arise  and  devalue  the  data  collected. 

Recovery  Planning  includes  the  source  of  information  to  be  used  to 
recreate  a  data  base  if  damage  has  occurred  to  it.  The  recovery 

procedures  must  be  concise  and  have  been  tested  to  ensure  they  work 
properly. 

4. 1.3. 7  Performance  Planning 

In  many  hardware  environments,  there  are  tools  to  measure  the 
performance  of  a  hardware/ software  environment.  These  usually  identify 
bottlenecks  and  provide  data  to  predict  performance.  Measurement  tools 
focus  their  attention  to  the  central  processing  unit,  memory  utilization, 
channel  utilization  and  access  mechanisms.  The  results  must  be 

interpretation  by  trained  personnel.  It  is  difficult  to  predict  the 


performance  of  a  application  software  due  to  "outside"  factors  such  as 
operating  system  overhead  and  limitations  of  hardware.  At  best  these 
models  permit  the  simulation  of  software  varying  parameters  that  may 
affect  the  system.  They  also  suggest  when  the  hardware  may  need  to  be 
upgraded. 

4. 1.3. 8  Data  Base  Conversion  Planning 

This  function  provides  the  strategy  and  plans  for  converting: 

•  Sequential  files  to  a  data  base  structure. 

•  Application  data  bases  to  subject  data  bases. 

•  Sequential  files,  application  or  subject  data  bases  to  MIS 
data  bases. 

Every  situation  must  be  considered  on  its  own  merits,  whether  a  DBMS 
will  provide  the  expected  benefits.  If  the  decision  is  positive,  the 
conversion  of  one  type  to  another  must  to  planned  such  that  users  are  not 
impacted.  In  performing  a  conversion  the  factors  in  Exhibit  4-15  must  be 
included  in  the  planning. 

4.1.4  Data  Distribution  Administration 

In  many  large,  geographically  dispersed  organizations,  such  as  DLA, 
it  is  necessary  to  determine  the  optimum  location  of  the  data.  This 
decision  is  complicated  by  the  purpose  of  each  system  (e.g.,  management 
information  system,  production  system)  and  its  data  characteristics 


(Exhibit  4-13). 


The  Data  Distribution  Administration  function  is  responsible  for 
determining  the  location  of  each  system,  its  data  requirements  (in 
conjunction  with  the  Data  Administrator),  whether  data  should  be 
duplicated  and  if  so,  its  updating  requirements,  and  how  should  the  data 
integrity  be  maintained.  The  Data  Distribution  Administration  function 
must  utilize  a  common  data  model  and  a  common  data  dictionary.  Tele¬ 
communications  network  design  and  network  workload  forecasting  are 
functions  that  must  interact  with  the  Data  Distribution  function  to 
ensure  that  the  telecommunications  capability  will  have  the  proper 
capacity. 

In  some  organizations,  the  Data  Distribution  Administration  function 
is  incorporated  into  the  Data  Administration  function  depending  on  the 
number  of  locations  and  whether  the  organization  is  in  a  implementating 
stage  of  development  or  a  maintenance  stage. 

4.1.5  Auditing  and  Security 

Security  has  been  referred  to  the  protection  of  resources  from  damage 
and  the  protection  of  resources  from  change  and  the  protection  of  data 
against  accidental  or  intentional  disclosure  to  unauthorized  persons  or 
unauthorized  modifications  or  destruction.  In  the  DLA  environment 
security  it  is  vital  to  the  process  of  its  mission. 

The  security  function  is  responsible  for  planning  and  implementing 
the  policy  and  procedures  necessary  to  protect  the  DLA  mission  and  its 
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investment  in  information.  There  are  three  areas  that  security  must 
address : 

•  Security  Authorization 

•  Address  Security  Breaches 

•  Security  Audits 

Security  authorization  is  responsible  for  permitting  the  proper 
individuals  access  to  required  information  and  securing  the  data  from  all 
other  individuals.  Access  to  data  refers  to  obtaining,  modifying,  or 
updating  via  computers. 

The  management  of  Security  Breaches  includes  the  methods  of  detection 
and  the  investigation  of  known  security  breaches.  Each  instance  should 
be  handled  according  to  the  established  policy  and  procedure. 

Security  Audits  are  a  function  that  will  improve  the  organizations 
awareness  of  security.  Audits  should  be  performed  randomly  and 
pre-scheduled  at  each  site  to  identify  potential  weaknesses  and  areas 
that  may  need  improvement. 
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DATA  BASE  CONVERSION  FACTORS 


1.  A  mapping  of  the  data  from  one  file  type  needs  to  be  made  with 
consideration  to  physical  storage,  changes  in  permissible  values, 
and  identification  of  keys. 

2.  Audit  trails  must  be  planned  and  implemented  during  actual 
conversion. 

3.  The  programming  (if  required)  and  testing  of  software  to  transfer 
the  data  from  one  file  type  to  another.  Application  software  will 
need  to  be  tested  to  ensure  that  it  can  read  the  resultant  data 
files . 

4.  Additional  computer  power  may  be  required  to  perform  the 
conversion  without  impacting  current  production  support. 

5.  The  timing  must  consider  other  organizational  requirements  (e.g., 
end  of  year  processing) 

6.  Parallel  testing  if  applicable,  of  the  current  system  with  the 
resultant  system  should  be  planned  and  implemented. 


EXHIBIT  4-15 
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POSITION:  DATA-DISTRIBUTOR 


LOCATION 
HEADQUARTERS , 


HEADQUARTERS , 


LOCATION 

HEADQUARTERS , 
AT  EACH  CDA 


ADVANTAGES 

DLm-ZW  •  COMPATIBLE  WITH 

SOME  CURRENT  MISSION 
STATEMENTS 

•  NOT  DIRECTLY 

DISTRACTED  BY  AIS 
PRESSURES 


DLA-2S  •  POTENTIAL  FOR 

TIES  ACROSS  AIS 
SYSTEMS 
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POSITION:  SECURITY  OFFICER 


ADVANTAGES 

DLA-ZW  AND 

AND  PLFA 

• 

COMPATIBLE  WITH 
CURRENT  MISSION 
STATEMENT 

• 

GIVES  GREATER 
VISIBILITY  TO  A 

HIGHLY  SENSITIVE 

AREA 

• 

MORE  DIRECT  FOCUS 
SECURITY  AND  AUDITING 
FUNCTIONS 

EXHIBIT  5-7 

DISADVANTAGES 

•  STAFF  MAY  BE  LACKING 
PROPER  SKILLS 


•  MAY  REQUIRE  ADDITIONAL 
STAFFING 


•  NOT  FULLY  COMPATIBLE 
WITH  CURRENT  MISSION 
STATEMENT 

•  NEW  FUNCTION  MAY  BE 
OBSCURED  BY  AIS 
PRESSURES 

$  MAY  REQUIRE  ADD":iONAL 
STAFFING 


DISADVANTAGES 

•  MAY  REQUIRE  ADDI¬ 
TIONAL  STAFFING 


•  POTENTIAL  OVERLAP 
WITH  DLA-T 
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POSITION: 


DATA-BASE  ADMINISTRATOR/ DESIGNER 


LOCATION 

ADVANTAGES 

DISADVANTAGES 

HEADQUARTERS,  DLA-ZW 

(DATA  BASE  MANAGEMENT  SYSTEM 

ADMINISTRATOR) 

t 

GENERALLY  COMPATIBLE  • 

WITH  CURRENT  MISSION 
STATEMENT 

ACQUIRES  ADDITIONAL 
SKILLS/TRAINING 

• 

PROVIDES  FOR  FOCUS 

ON  PHYSICAL  DATA  BASE 
DESIGN  TECHNOLOGY 

• 

PROVIDES  FOR  CEN¬ 
TRALIZED  CCDORDINATION 

AND  GUIDANCE  ON 
STANDARDIZING  DBMS 
SELECTION 

CDA  •  COMPATIBLE  WITH  •  ADDITIONAL  SKILLS/ 

(DATA  BASE  CURRENT  MISSION  TRAINING  REQUIRED 

DESIGNER) 

•  PROVIDES  FOR  CLEAR 
FOCUS  ON  DATA  BASE 
DESIGN  AND 
IMPLEMENTATION 
FUNCTION 


PLFA  (DATA  BASE  DESIGNER) 


•  KNOWLEDGE  OF  UAIS 
IMPLEMENTATIONS 


t  POTENTIAL  LACK  OF 
PROPER  SKILLS 


•  PROVIDES  FOR  CLEAR 
FOCUS  ON  DATA  BASE 
DESIGN  AND 
IMPLEMENTATION 
FUNCTION 


•  MAY  REQUIRE  ADDIT 
lONAL  STAFFING  AT 
SOME  SITES 


EXHIBIT  5-5 
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POSITION:  DATA  ADMINISTRATOR  (CONTINUED) 


LOCATION 


ADVANTAGES 


DISADVANTAGES 


HEADQUARTERS 

PERFORMED  BY  AIS 

ADMINISTRATORS 

(DLA-ZS) 


•  METADATA  IS  COLLECTED 
DURING  ANALYSIS  PHASE 


•  AIS  ADMINISTRATOR 
SYSTEM  KNOWLEDGE 


•  POTENTIAL  FOR 
LIMITED  FUNCTIONAL 
AREA  INVOLVEMENT 

•  TRAINING 


HEADQUARTERS 

CREATE  DATA  ADMINISTRATOR 
FUNCTION  UNDER  AIS 
ADMINISTRATOR 
(DLA-ZS) 


5.5  DBMS  Security  Officer 


•  DATA  ADMINISTRATOR 
WORKS  CLOSELY  WITH 
AIS  ADMINISTRATOR  AND 
FUNCTIONAL  USERS 

•  PROVIDES  ASSISTANCE 
TO  AIS  ADMINISTRATOR 


EXHIBIT  5-4  (continued) 


§  POTENTIAL  MANPOWER 
CEILING  LIMITATIONS 


•  POTENTIAL  FOR  LESS 
ATTENTION  DUE  TO 
AIS  DEMANDS /WORKLOADS 


This  position  is  responsible  for  the  security/privacy  issues  related 
to  data  and  data  base  management  systems.  There  should  be  a 
representative  at  each  level  of  the  organization.  Exhibit  5-7  presents 
the  advantages/disadvantages  of  the  DBMS  Security  Officer. 
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POSITION:  DATA  ADMINISTRATOR 

LOCATION  ADVANTAGES  DISADVANTAGES 

•  HIGH  FUNCTIONAL  USER  •  DATA  SHARING  ACROSS 

SUPPORT.  WORK  CLOSELY  SEVERAL  FUNCTIONAL 

WITH  END  USERS  AREAS  WILL  REQUIRE 

INTENSIVE 
COORDINATION 

•  BETTER  FUNCTIONAL  f  HIGH  NEED  FOR 

PARTICIPATION  IN  DATA  ADDITIONAL  SKILLS/ 

PLANNING  TRAINING 

•  MINIMIZES  COMPLEXITY-  •  MAY  REQUIRE 

ADDITIONAL 

MULTIPLE  DAS  EACH  STAFFING 

HANDLING  DIFFERENT 
SUBJECT  AREAS 


•  RETAINS  FAIRLY  HIGH  •  POTENTIAL  FOR  BEING 

FUNCTIONAL  USER  OBSCURED  BY  AIS 

SUPPORT  PRESSURES 

•  CONTINUES  PARTICIPA-  •  NEED  FOR  ADDITIONAL 

TION  IN  LOGICAL  DATA  SKILLS/TRAINING 

MODELING 

•  REDUCES  COMPLEXITY  •  MAY  REQUIRE 

AND  INTENSIVE  ADDITIONAL  STAFFING 

COORDINATION 


CDA'S  AND  PLFA'S—  ONE  PER  •  FUNCTIONAL  RELATION-  t  MAY  REQUIRE  ADDI- 

SITE  SHIP  FROM  FIELD  TO  TIONAL  STAFFING 

HQ 

•  PROVIDES  FOR  LOGICAL  §  NEED  FOR 

DATA  MODELING  FOR  ADDITIONAL  TRAINING 

UAIS  DATA  FOCUS 

f  TOP  LEVEL  DATA  FOCUS 

EXHIBIT  5-4 


HEADQUARTERS.  ONE  IN  EACH 
FUNCTIONAL  AREA  WITH 
MINIMUM  DATA  SHARING  OUTSIDE 
THE  AREA;  ONE  IN  DLA-ZS 
FOR  MULTIPLE  FUNCTIONAL 
AREAS  WITH  HIGH  LEVEL 
OF  DATA  SHARING 


HEADQUARTERS.  ONE  IN  EACH 
MAJOR  FUNCTIONAL  AREA 
(e.g..  DLA-K.  DLA-0) 
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POSITION:  DATA  STRATEGIST 


LOCATION 
HEADQUARTERS , 


HEADQUARTERS. 


ADVANTAGES 

DLA-2S  •  STRONG  ADVOCATE  OF  • 

DATA  PLANNING 


•  PARTLY  INCLUDED  IN  • 
CURRENT  MISSION 


•  ESTABLISHED  • 

MECHANISM  FOR 
ARBITRATION  ROLE 


DLA-L  •  CO-LOCATED  WITH  • 

BUSINESS  PLANNING 
FUNCTION 

•  BETTER  POTENTIAL  FOR  • 
STRATEGIC  DATA 
PLANNING 

• 


•  BETTER  POTENTIAL  FOR  t 

FUNCTIONAL  COOPERA¬ 
TION 

•  CORPORATE  DATA  FOCUS  • 


•  FLEXIBILITY  FOR 
GROWTH 

•  ESTABLISHED  MECHANISMS 
FOR  RESOLVING  RESOURCE 
CONFLICTS 


EXHIBIT  5-3 


DISADVANTAGES 

POTENTIAL  FOR  BEING 
OBSCURED  BY  AIS 
PRESSURES 

POTENTIAL  FOR  LIMITED 
FUNCTIONAL  AREA  IN¬ 
VOLVEMENT 

REQUIRES  ADDITIONAL 
STAFF  SKILLS/TRAINING 


■POTENTIAL  TO  LIMIT 
FOCUS  ON  PROGRAM/ 
PLANNING  INFORMATION 

LIMITED  STAFF 
EXPERIENCE 

REQUIRES  ADDITIONAL 
STAFF  SKILLS/TRAINING 

NEW  POSITION  MAY 
REQUIRE  APPROVAL 


NEED  FOR  SUPPORT 
STAFF  WITH  APPRO¬ 
PRIATE  SKILLS 
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separate  position.  The  choice  should  be  determined  by  the  amount  of 
data  to  be  analyzed  and  the  importance  it  is  to  present  this 
analysis.  It  would  be  possible  to  fold  the  Data  Distribution 
functions  into  the  Data  Administration  upon  accomplishment  of  the 
initial  Data  Distribution  functions.  Exhibit  5-6  presents  the 
advantages/disadvantages  of  the  Data  Distribution  position. 
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5.2  Data  Administrator 


Regardless  of  the  organization  level  in  DLA,  the  Data 
Administrator  position  has  greater  political  and  semantics  aspects 
than  technical  aspects.  The  Data  Administrator  should  be  a 
excellent  communicator.  He/she  will  have  to  work  with  functional 
people  and  highly  technical  people  to  accomplish  the  Data 
Administration  responsibilities.  Exhibit  5-4  lists  the 
advantages/disadvantages  of  the  Data  Administrator  position. 


5.3  Data  Base  Administrator/Designer 

This  position  is  responsible  for  the  Data  Base  Management  System 
software  and  the  physical  design  of  databases.  The  skills  needed  to 
perform  these  functions  are  highly  technical  and  the  individual  in 
this  position  will  require  training  to  remain  knowledgable  with  the 
state  of  the  art.  Exhibit  5-5  illustrates  the 
Advantages/Disadvantages  of  the  potential  positions  of  the  Data  Base 
Administrator. 


5.4  Data  Distribution  Analyst 

This  position  will  be  responsible  for  determining  the  location 
of  data  in  a  distributed  data  processing  environment.  These 
functions  may  be  performed  by  the  Data  Administrator  or  as  a 


SECTION  5.  PROPOSED  ORGANIZATIONAL  DESIGN 


e 

In  the  previous  section  we  addressed  the  required  D/DBA 
functions  and  supporting  tools.  This  section  addresses  where  should 
the  functions  and  tools  be  located  throughout  DLA.  These  positions 
are  presented  for  different  organization  levels  (e.g..  Headquarters, 
Central  Design  Agencies,  Primary  Level  Field  Organizations)  within 
DLA.  Exhibit  5-1  illustrates  the  suggested  D/DBA  locations  within 
the  DLA  organization.  Exhibit  5-2  identifies  the  responsibilities 
of  each  position  at  the  various  DLA  organization  levels.  A 
discussion  of  the  position  locations  follow. 

5.1  Data  Strategist 

This  position  will  require  a  senior  level  individual  who  is 
knowledgeable  in  the  overall  management  and  functional  business 
goals  and  objectives  and  can  communicate  well  with  the  DLA  top  level 
management.  The  important  consideration  is  the  support  received 
from  management.  The  Data  Strategist  must  be  in  a  position  to 
diplomatically  change  the  organizations  view  and  management  of 
data.  Two  logical  locations  for  this  function  are  DLA-L  and  DLA-Z. 
Exhibit  5-3  lists  the  advantages/disadvantages  of  the  Data  Strategic 


position. 


SECTION  6.  IMPi^EMENTATION  PLAN  FACTORS 


This  section  discusses  factors  pertaining  to  the  development  of 
a  D/DBA  Administration  program  implementation  plan.  A  detailed  plan 
needs  to  be  coordinated  with  DLA  Headquarters,  the  CDAs,  and  the 
PLFAs.  As  stated  earlier,  managing  an  effective  data/data  base 
environment  must  have  the  full  support  of  upper  management.  This  is 
necessary  to  overcome  resistance  to  change  and  to  foster  a  DLA-wide 
"state  of  mind"  that  data  is  a  key  organization  resource.  The 

following  factors  should  be  considered  when  designing  an 

implementation  plan. 

6.1  Phased  Approach 

A  phased  approach  is  preferable.  Considering  the  size  and 
complexity  of  DLA,  a  single  large  effort  is  doomed  to  great  expense 
and  failure.  Use  of  a  phased  program  implementation  will: 

•  Capitalize  on  existing  D/DBA  administration  policies  and 
functions  that  are  already  in  place. 

•  Distribute  the  resource  requirements  for  implementation  over 
a  longer  period  of  time  allowing  a  more  balanced  use  of 
personnel  and  funds 

•  Permit  sufficient  lead  time  for  the  CDAs  and  PLFAs  to  prepare 
for  program  implementation 

•  Allow  DLA  Headquarters  an  initial  period  of  time  to  begin  a 
large  organizational  learning  process 

•  Enable  DLA  Headquarters  to  focus  on  certain  D/DBA  activities 
which  will  produce  positive  substantial  early  results 


Implementing  an  D/DBA  program  in  DLA  will  require  a  considerable 
effort  by  many  individuals  and  organizations  dispersed  throughout  the 
agency.  By  following  a  phased  approach,  time  will  be  available  to  create 
an  understanding  of  the  needs,  benefits,  and  philosophy  of  the  D/DBA 
environment  and  provide  an  organizational  setting  to  foster  a  sense  of 
participation  on  a  DLA-wide  basis. 

We  suggest  that  the  D/DBA  concepts  enumerated  in  Section  3  be 
implemented  first  within  an  AIS  administrative  area  such  as  SAMMS.  This 
would  involve  several  major  SAIS,  (e.g.,  SAMMS,  DWASP,  MOCAS)  and  several 
DLA  organizations. 

6.2  OLA  Wide  Education  Program 

The  commitment  to  implement  a  D/DBA  program  places  responsibilities 
on  anyone  involved  with  the  use  and  management  of  data.  This  includes 
both  the  Data  Processing  personnel  and  users.  To  make  this  D/DBA  effort 
effective  and  sustaining,  DLA  will  have  to  commit  to  an  ongoing  and 
continuous  education  program  that  addresses  D/DBA  topics  and  concepts. 
During  the  initial  phase,  an  overview  of  D/DBA  and  its  impact  upon  the 
DLA  communities  should  be  presented  to  appropriate  personnel  regarding 
the  D/DBA  nature  and  its  expected  benefits.  As  the  program  evolves, 
greater  detail  educational  programs  will  be  developed,  and  more  technical 
D/DBA  orientations,  classes,  and  courses  can  be  conducted. 

The  various  positions  described  above  may  require  special  seminars 
and  vendor  specific  packages.  Training  for  the  technical  aspects  are 
listed  in  Exhibit  6-1. 


TRAINING  REQUIREMENTS 


[ 


Position  * 

Security/Privacy  Analyst 


Data  Distribution  Analyst 


Data  Base  Administrator/ 
Designer 


Data  Administrator 


Data  Strategist 


Security 

Privacy 

DBMS  Concepts 


Logical  Data  Design 
DBMS  Concepts 
DD/D 


DBMS  Concepts 
DBMS  Physical 
Design 
DD/D 

Logical  Data  Design 
DBMS  Concepts 
DD/D 

Logical  Data  Design 
DBMS  Concepts 
DD/D 

Security 

Privacy 
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Many  of  these  courses  are  available  commercially  and  may  be  on 
Videotape.  DLA  should  invest  in  the  method  that  will  provide  the 
greatest  return  on  investment. 

6.3  Excessive  Application  Development  Pressure 

An  organization  is  always  going  to  be  requested  to  develop 
applications  quickly  and  under  a  large  amount  of  pressure.  The 
organization  must  develop  a  policy  to  effectively  address  these  requests 
while  still  maintaining  the  D/DBA  in  perspective.  If  this  is  not  done. 
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the  D/DBA  program  will  not  obtain  the  benefits  that  it  promises  (e.g., 
lower  maintenance  costs). 

The  D/DBA  program  should  have  a  set  of  priorities  by  which  to  judge 
requests.  Efforts  to  bypass  or  ignore  the  priorities,  should  be  quickly 
brought  to  a  halt  by  management. 

6.4  Conversion  Considerations 

At  some  point  the  organization  must  decide  whether  to  convert 

•  files  to  application  or  preferably  subject  data  bases 

•  application  databases  to  subject  databases. 

These  decisions  are  difficult,  but  can  be  made  rationally.  If  the 
existing  system  is  performing  properly,  the  users  requirements  are  being 
satisfied  and  the  maintenance  costs  are  reasonable,  then  a  conversion 
should  be  performed  on  another  system. 

If  a  conversion  is  chosen,  it  should  be  well  planned  and  discipline 
should  prevail.  To  increase  the  percentage  for  success  the  following 
items  should  be  addressed: 

•  The  use  of  automated  tools  (e.g.,  data  dictionaries,  data 
modeling)  to  support  the  effort 

•  The  data  should  be  in  a  normalized  form 

•  The  data  structure  from  the  current  system  should  be  used  if 
it  is  still  valid 

•  The  conversion  should  be  phased  to  continue  to  support  the 
user  in  a  adequate  manner 
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A  conversion  is  the  joint  effort  of  the  Data  Strategist,  Data 
Administrator,  Data  Base  Administrators/Designer  and  the  application 
design  personnel.  The  conversion  will  only  be  as  successful  as  the 
amount  of  effort  expended  to  plan  and  prepare  for  it. 

6.5  Automated  Tools 

Previously  automated  tools  were  discussed  as  to  their  importance  to 
the  D/DBA  environment.  The  functions  performed  by  the  Data 
Administrator (s)  and  Data  Base  Administrator( s ) /Designer { s )  are  large  and 
complex.  The  metadata  defined  and  the  relationships  require  the  support- 
of  automated  tools.  These  should  be  investigated  by  DLA  and  standard 
tools  obtained  (either  developed  or  acquired). 

We  suggest  that  as  part  of  an  initial  implementation  phase,  DLA 
should  quickly  decide  on  automated  tools  for  their  Data  Dictionary  (e.g., 
MSS,  TIS)  and  a  Data  Modeling  Tool  (e.g..  Data  Designer). 

Procedures  will  have  to  be  integrated  with  the  tools  to  ensure 
standard  usage  throughout  the  DLA.  Where  necessary,  bridges  need  to  be 
developed  to  transfer  data  from  one  tool  to  another  with  minimal  human 
intervention.  Without  these  tools  the  D/DBA  functions  will  be  unable  to 
meet  the  needs  of  the  DP  community  and  may  contribute  to  the  failure  of 
the  D/DBA  effort. 
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6 . 6  Summary 


The  implementation  of  a  D/DBA  activity  should  not  be  taken  lightly, 
because  there  are  many  factors  that  may  defeat  it.  These  include 

•  Organization  Politics 

•  Lack  of  a  clear  set  of  goals 

•  Lack  of  a  training  plan 

•  Lack  of  top  management  commitment 

A  phased  controlled  approach  should  be  taken  with  identifiable  milestones 
to  demonstrate  progress  to  the  management  and  organizational  community  at 
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